Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(serde_at): deserialize _ #216

Merged
merged 2 commits into from
Jan 20, 2025

Conversation

denysvitali
Copy link
Contributor

@denysvitali denysvitali commented Nov 28, 2024

While parsing the CGMI of my device (SIM7020), I've noticed that I was getting a lot of parsing errors.
After digging deeper, I've discovered that the parsing errors were actually EofWhileParsingString errors.

Finally, I've discovered why: my manufacturer string looked like this:

SIMCOM_Ltd

And this was breaking at the _, because it's not considered alphanumeric.
My fix here is to allow all ASCII characters >= 32 (space + printable characters).

The only non-printable character included is DEL (127) - but it shouldn't be a big deal.


match client.send(&common::GetManufacturerId{}).await {
    Ok(resp) => {
        info!("Manufacturer ID OK: resp={:?}", resp.id.as_str());
    }
    Err(e) => {
        println!("Error: {:?}", e);
    }
}

Before my fix:

DEBUG Response: "SIMCOM_Ltd"
Error from serde_at: EofWhileParsingString

After my fix:

DEBUG Response: "SIMCOM_Ltd"
INFO Manufacturer ID OK: resp="SIMCOM_Ltd"

@MathiasKoch
Copy link
Member

This looks good to me 👍

Sorry for the long response time. Would you mind rebasing this?

Thank you for the contribution!

@denysvitali denysvitali force-pushed the fix/serde-at-underscore branch from e3b191f to 000bf7d Compare January 15, 2025 06:39
@denysvitali
Copy link
Contributor Author

Done :)

@MathiasKoch
Copy link
Member

Seems like tests are failing, and rustfmt

@denysvitali
Copy link
Contributor Author

I can't understand the real reason why the test that is now passing should have been invalid in the first place.

https://github.com/FactbirdHQ/atat/blob/master/atat/src/blocking/client.rs#L426-L448

The returned value (after this PR) is now:

Ok(TestResponseString { socket: 22, length: 16, data: "22" })

instead of being a parsing error.

Can you please help me understand if this test should really fail? I don't see why the test was created...

@MathiasKoch
Copy link
Member

That is a very valid point! It does look wrong to me aswell!

As does this test though:

async fn response_string() {
let (mut client, mut tx, rx) = setup!(Config::new());
// String last
let cmd0 = TestRespStringCmd {
fun: Functionality::APM,
rst: Some(ResetMode::DontReset),
};
let response0 = b"+CUN: 22,16,\"0123456789012345\"";
// Mixed order for string
let cmd1 = TestRespStringMixCmd {
fun: Functionality::APM,
rst: Some(ResetMode::DontReset),
};
let response1 = b"+CUN: \"0123456789012345\",22,16";
let sent = tokio::spawn(async move {
let sent0 = tx.next_message_pure().await;
rx.signal_response(Ok(response0)).unwrap();
let sent1 = tx.next_message_pure().await;
rx.signal_response(Ok(response1)).unwrap();
(sent0, sent1)
});
tokio::task::spawn_blocking(move || {
assert_eq!(
Ok(TestResponseString {
socket: 22,
length: 16,
data: String::<64>::try_from("0123456789012345").unwrap()
}),
client.send(&cmd0),
);
assert_eq!(
Ok(TestResponseStringMixed {
socket: 22,
length: 16,
data: String::<64>::try_from("0123456789012345").unwrap()
}),
client.send(&cmd1),
);
})
.await
.unwrap();
sent.await.unwrap();
}
?

Response arguments are fixed positions, and cannot just be anywhere in the response?

I have not used the blocking client even once since we introduced the async one, so i guess these test cases must have slipped by my review a long time ago :/

@denysvitali
Copy link
Contributor Author

Should I remove this test then?

@MathiasKoch
Copy link
Member

Yeah, lets go ahead and do that 👍

@MathiasKoch MathiasKoch merged commit aeb67d5 into FactbirdHQ:master Jan 20, 2025
8 checks passed
@MathiasKoch
Copy link
Member

Thanks!

@denysvitali denysvitali deleted the fix/serde-at-underscore branch January 20, 2025 21:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants